1. Field of Art
The present application relates to provided a method of and apparatus for providing communication between two or more software elements. The invention disclosed herein has particular, but not exclusive, application to dynamic real-time distributed systems with highly mobile software elements.
2. Related Art
Well known examples of present-day architectures used by such applications to enable the interaction of a number of clients will be discussed having regard to FIGS. 1(a)-(b) and 2.
FIG. 1(a) illustrates a very simple interconnection of each client to all other clients. It will be clear that such an approach will very quickly become impractical as the number of clients rises. It might easily be wished that, for example, one hundred clients are to interact.
FIG. 1(b) illustrates a more sophisticated approach where each client is connected to a single central server. The concept of a client/server arrangement and associated terminology will be well known. However, as soon as the number of clients begins to rise this approach also becomes impractical. If, for example, hundreds of clients were to interact in any non-trivial manner, a single present-day server would simply be overwhelmed by both the computational load and the network traffic.
FIG. 2 illustrates a more sophisticated approach where each of a number of clients is now connected through an interface not to a single central server but to a server cluster comprising multiple servers. Whilst this approach retains the ability to manage the application in a central fashion at the server cluster, it also allows both the computational load and the network traffic to be distributed amongst the multiple servers of the server cluster.
It will be well known that a so-called object-oriented approach to computer programming has become widespread over the past few years and applications such as large multi-player games are no exception. The concept of an object and associated terminology will be well known. The term ‘game component’ will here be used to refer to a game object, i.e. any self-contained grouping of code and data that represents some aspect of a game implementation.
Typically, each of the servers of the server cluster will be running multiple processes and each process will be hosting multiple game components. It will be understood that with this approach that there will be some components, for example a so-called ‘login manager’, that are only to be instanced once, at a fixed location. Other components, for example a disintegrator pistol, might be instanced many times, in many different locations. Indeed, it might well be the case that such a component might be passed from a first game-player, playing on a first client, to a second player, playing on a second client. In this way, it would be necessary for the component to move from the first client up to the server cluster and then back down to the second client.
This architecture will also be required to be dynamic in other ways.
As the size or complexity of such multi-player games increases or as the number of joined clients increases, it may be desired to increase the number of servers in the server cluster. As mentioned above, in this way the computational load associated with the hosting of the game and the network traffic generated in the course of playing the game may be distributed or balanced over a number of individual servers. It may also be desired for new servers with particular functionality to be joined to the server cluster, for example a sophisticated Artificial Intelligence (AI) engine.
Further, as the game environment evolves, it may well be the case that the computational tasks required to maintain it change. New processes may be created and old processes destroyed as required.
The developer of applications such as large multi-player games therefore faces a considerable challenge in working with such a highly dynamic and distributed architecture. It will be clear that, in particular, the problem is posed of allowing such real-time, low latency communication between the distributed game components as will allow a highly dynamic and distributed multi-player game to be played.
Given the widespread interest in object-oriented computer programming as mentioned above, it is well known that there are, at the present time, a number of approaches to allowing objects to communicate with one another. Of particular interest, having regard to the abovementioned problem, are the different approaches to allowing so-called distributed objects, which is to say distributed over a client/server system, to communicate with one another.
A good introduction may be found in ‘The Essential Distributed Objects Survival Guide’, By Robert Orfali, Dan Harkey and Jeri Edwards, published by John Wiley & Sons Inc in 1996.
By way of a first example, a client/server implementation might be implemented simply using the standard Transmission Control Protocol/Internet Protocol (TCP/IP) Berkeley socket API. However, many problems would immediately arise including:    (a) Each client would have to continually create and destroy connections to all the relevant server processes (where the definition of ‘relevant’ changes regularly) introducing problems of latency and processing overhead.    (b) Game components changing their location (i.e. moving between processes) would create problems of location tracking and data sequencing. While a TCP/IP link guarantees data ordering between each end, communication between mobile game components will involve multiple TCP/IP links, where no relative sequence information is maintained.    (c) The enforced sequencing of TCP/IP links can dramatically increase the perceived latency between clients in the environment. For example, if in the sequence ‘Player A says hello, Player B shoots you’, the first element is lost in transit, then the second element will be delayed whilst a timeout/retransmission mechanism is invoked.
A further simple implementation might use User Datagram Protocol/Internet Protocol (UDP/IP) instead of TCP/IP. However, whilst the enforced sequencing problem is removed, so is, for example, any concept of data sequencing or reliable delivery.
The now well known Common Object Request Broker Architecture (CORBA) and Distributed Component Object Model (DCOM) provide generic mechanisms for sharing information between distributed objects over a network. However, the basis of the CORBA/DCOM approach has been to try and hide the very existence of the network in providing a uniform object interface. Whilst these are powerful techniques, they are not applicable to highly time-critical and traffic volume sensitive applications. It is instead essential to maintain control over how network traffic is distributed and handled. Related technologies may, for example, for example, rely on the asynchronous retrieval of messages from a centralized queue.
Thus, these present-day approaches are simply not able to provide a solution to the problem outlined above.